当飞猪遇上 Serverless | 云原生 Talk
The following article is from Fliggy F2E Author 承荫
前言
2019 年 3 月，我们跟随着集团的步伐，将 Serverless FaaS 引入到飞猪，并取得了一定的阶段性成果：
这一年，我们参与共建了 Node FaaS 研发平台和稳定性监控大盘；
这一年，我们落地了 13 个业务场景，上线了30+函数，单日调用峰值达到2000w；
这一年，我们参与或者使用 FaaS 的开发人员占飞猪前端人员 33% 以上，其中 50% 是初次参与服务端开发；
2020 年， Serverless 和飞猪的故事故事还在继续，立足当下，展望未来的同时，我们仍需了解下历史，回到最开始的时候……
架构的演进
在看 Serverless 之前，我们先分别从服务器和软件架构的视角分别回顾一下各自演进过程的几个重要阶段；
服务器视角
物理机时代：很久以前，上线一个站点，需要自己买物理机，安装操作系统和数据库，所有的代码部署在一起，申请网址，维护这台机器的用电和网络，这个阶段出现了一个角色叫 PE（运维），是专门来维护这一套运行环境，开发过程极其艰难；
IaaS 时代：随后的 IaaS（Infrastuctrue as a Service）是一个质的飞跃，这个阶段把物理机切割成一个个虚拟机，屏蔽了直接对物理机和操作系统、域名绑定等基础设施的操作和维护，降低了一定的运维成本，也极大地提高了对机器资源的利用率，但这个阶段开发人员还需要去搭建和维护自己的代码运行环境和监控，PE 仍存在着；
PaaS 时代：PaaS（Platform as a Service）是在 IaaS 基础上的扩展，这个阶段开发人员不但不需要关心机器的磁盘，内存和操作系统等基础设施，而且代码的运行环境、监控都不需要关心，和容器镜像技术的完美配合，让开发人员只需要把自己可运行的代码“扔”上去就行，这个阶段很多公司的PE这一角色成为了历史，应用开发开始大跨步前进。
FaaS 时代：如果说 IaaS 到 PaaS 让开发脱离了物理机和运维，那么 FaaS（Function as a Service）则让我们忘记了机器的存在，开发不再关心机器的容量和健康度，甚至不用关心代码的依赖框架的版本，真正做到只关心业务代码，这一阶段机器被分割到更小的粒度 Pod ，按使用计费和自动缩扩容的特性让人着迷，我们开始迈向真正的 Serverless 。
软件架构视角
在从软件架构的视角来看，主要经历了这几个阶段；
1、单体应用
最开始的一个软件架构包含了前端、业务逻辑和数据库层，这一阶段开发上线一个业务可能是成本最低的，也可能是最高的，所有的代码都在一个地方开发、部署，具备极小的协同成本。但是随着业务的发展，功能增多，这个架构越来越膨胀，开发一个功能变得越来越难，Bug 也越来越多，最终成为开发者的噩梦，重构仿佛是惟一的出路，但这条路成本高昂且不治本，因此，分布式架构脱颖而出。
2、分布式架构
分布式架构是将一个单体应用分隔成多个领域应用，例如商品中心 IC 、营销中心 UMP 、交易中心 BUY ，各个应用可以通过接口相互调用，由此衍生了我们熟知的 Dubbo 、 HSF 等 RPC 框架，远程接口调用虽然带来了性能的损耗，但是分布式架构对于后期的维护，功能的复用所带来的价值，利远大于弊，并能有力地支撑着业务快速发展。
3、微服务
微服务也是近些年比较火的一个架构，简单来说就是将单体应用细分为多个专业的服务，分别部署不同的服务器，也可以部署在一个服务器的多个容器，可以理解为是对分布式应用服务的再细化。
4、模板解耦
在单体应用时代，前端代码和服务端代码完全杂糅在一起。随着前端的迅猛发展，我们将 js/css 等静态资源分离出来维护并部署到 CDN 。由于PC时代页面需要绑定不同域名以及同步渲染等能力，所以模板一直部署在服务端代码包中，这就造成了前端模板和静态资源的割裂，以及和服务端的耦合，由此诞生了众多的前后端分离方案，其中最为常见便是 Node.js 做 BFF 中间层支持 SSR ，其目的还是为了让前后端都能具备高度的开发效率。
5、视图解耦
2011 年前后，随着无线时代到来，开始了 Mobile 为王、PC 黯然退场的阶段，前端页面的展示从宽大的浏览器搬到了各个窄小的手机 App ，用户不再看到域名，同步渲染似乎也不是很重要，这个时候前后端模板自然解耦，而离线包和 Native 造成的长尾效应的出现，对数据驱动视图提出了更高的要求，服务端需要更加关注视图逻辑，这就又出现了新的问题——前后端视图的耦合，由此出现了很多方案去降低这种耦合，例如曾经的无线服务端岗位专门处理视图逻辑，再比如奥创、GPF、DinamicX 等领域解决方案。
从服务器和软件架构的演进历程，可以总结出一个目标，那就是“专业的人做专业的事情”，也就是实现云厂商专注于服务器的维护，专业领域应用开发提供专业的服务，业务应用开发专注于业务逻辑，前端则掌控静态资源、模板和视图，各自间协同作战又互不影响。
Serverless 的兴起
Serverless 概念最早提出可以追溯到 2012 年，无服务器架构是指服务端逻辑由开发者实现，应用运行在无状态的计算容器中，由事件触发，完全被第三方管理，AWS 的 Lambda 最早推出相应的实践，目前最流行的两种 Serverless 架构分别是 FaaS（Function as a Service），如阿里云函数计算FC；CaaS（Container as a Service），如 Serverless 容器服务 ASK ，其中 FaaS是应用最广泛的。
Serverless 的发展历程
2012 年甚至更早，Serverless 的理念被提出来，无服务化的想法让全球很多开发者着迷，至此埋下了一颗希望的种子；
2014 年， AWS 发布 Lambda ，真正意义上实现了无服务化的架构并且商业化，一时间刺激了各大云厂商的神经，Google Cloud Function 和微软 Azure Function紧随其后，并取得了成功；
2016 年，云栖大会上特别设置了 Serverless 专场，开始了在 Serverless 领域的布局，阿里云因此成为国内首个提供 Serverless 计算服务的云厂商。随后，腾讯云、华为云迅速跟进投入。
2019 年，阿里研究员毕玄的一篇《Serverless：云时代的软件架构核心思想》在集团内引发了热烈讨论，同年 4 月，Aone 联合 Ginkgo 开始打造面向集团内开发者的 Serverless FaaS 服务，与此同时，前端将 Serverless 作为该年重点方向之一，飞猪深入参与其中。这一年，前端作为集团 Serverless 的先行者，开发了研发平台、 Midway FaaS Runtime ，并落地大量场景。
2020 年，阿里云函数计算突破了弹性扩容的速度和 0-1 的弹起速率的挑战，研发平台前端团队希望通过研发平台 2.0 提升研发体验和稳定性，而飞猪则在围绕稳定性、体验、规模化、可度量方面推动 Serverless 定位的转变（技术探索 -> 生产力工具），服务端的开发模式的转变（PaaS -> FaaS），前端职责的转变（端 -> 云 + 端）。
飞猪技术架构的发展脉络
从 2012 年的淘宝旅行（飞猪的前身）开始，不管是服务器还是软件架构都已经发展了很久，站在巨人的肩膀之上，飞猪的技术架构经历了几个特殊的阶段：
1、服务器架构
IaaS + PE（2012 - 2016）：这时候飞猪还叫淘宝旅行，这个阶段应用的申请、部署、机器的操作、域名的绑定等有专门的PE支持，机器的划分使用的是阿里自建的虚拟机技术 T4 ，运维在这个时期对于开发是一个比较复杂的能力，所以需要有专人支持，让开发专注于代码层面，但这种配合机动性较差，上线一个应用往往涉及人员较多，时间较长，极大地束缚了业务的开发。
PaaS + DevOps（2016 - 2019）：随后容器技术的出现，使得运维发生了革命性的变化，容器技术和镜像的完美结合，极大地简化了运维的模式，让开发懂得一点简单的运维能力就可以支撑应用的正常运行，阿里将 T4 和 Docker 结合产出 AliDocker ，并推进了全集团应用的升级，随之顺利推进了DevOps的转变，从此 PE 这个角色在阿里成为历史。
PaaS + FaaS（2019 - 至今）：2019 - 2020年飞猪引入 FaaS 的能力，由前端作为先锋，和集团 Node 等多个团队一块进行基础建设和业务试点，取得了阶段性结果，获得了一些定性的结论，其中最重要的结论是 FaaS 对于效率的提升和资源的节省有突破性进展，在某些场景可以和传统 PaaS 应用实现互补，自此我们开始 Serverless 的建设之路。
2、软件架构
PC VM（2012 - 2014）：在 PC 为王的时代，由于独立域名、同步渲染等要求，应用需要各自维护页面模板，而此时 VM 模板是阿里 Java 框架 Webx 中的重要一环，此时前后端因为模板的耦合造成了开发体验、线上稳定性等问题，这个阶段随着 PC 的落幕而逐渐成为历史。
前后端分离（2014 - 2017）：这个阶段可以说是 PC 时代的小插曲，为了能让前后端解耦去解决效率和稳定性的问题，前端同学尝试了很多方案，例如由前端单独部署 xsl 、vm 模板，使用 Node.js 解析 velocity 语法在本地模拟一套 VM 运行的环境等，其中最为有效的便是用 Node.js 应用做中间层配合 SSR 实现前端对视图的掌控，这套BFF架构解决了前后端分离的问题，并在没有增加太大工足量的同时，保留了同步渲染的能力，适合一些需要做 SEO 或者要求秒出的核心页面。
无线服务端（2014 - 2016）：这是 PC 向无线过渡的特殊时期，和 PC 时期不同的是，无线对数据模型的要求更为苛刻，另外 MTOP 网关也是对无线的特殊产物。过渡时期由于业务开发对这两点的适应需要一个过程，所以出现了无线服务端这个历史产物，其最大的工作就是作为介于业务服务端和端之前的一层，实现数据的聚合和处理，在过渡期实现业务的快速前进，完成了历史的使命。
领域解决方案（2016 - 2020）：随着业务的发展，新的难点出现，如飞猪商品发布页、详情页，和下单页需要承载Wi-Fi电话卡、签证、线路、酒店团购等几十个类目，此时各个系统和页面已经变得十分臃肿，稳定性和效率都被拖累的“弹指可破”，于是出现了商品发布的 GPF ，详情域的 TUD 和交易域的奥创等领域解决方案。其中交易域的奥创结合 DinamicX 演化为现在的新奥创，并通过平台化统一了飞猪的全域下单。
FaaS BFF（2019 - 至今）：在 Node FaaS 出现之前，前端几乎没有涉及无线服务侧的领域。总结下来有两个原因：一是集团 Node.js 一直没有支持 MTOP 的去中心化，二是应用运维和开发带来的高难度和移动端不太需要 SSR 的特性，造成的投入产出比太低。但是前端需不需要做服务侧的开发，答案是肯定的。因为对于业务服务端开发来说，不太想处理前端要求苛刻的 VO 模型，而前端也迫切希望完全掌控视图逻辑，此时 Node FaaS 的出现完美的解决了运维开发的难度和 mMTOP 的问题，释放了业务服务端，赋能了前端，其中典型的实践便是使用 FaaS 实现评价发布器中间层。
未来的发展规划
Serverless 的定位
to 前端：对于前端来说，Serverless 领域我们常用到的是 FaaS 模式，目前来看我们主要将其定位在应用于两种场景：一是在 C 端场景作为中间的胶水层使用，主要实现的是数据的处理，包括合并接口、协议转换，以及部分场景可能用到的 ABtest、SSR ；二是应用于中后台场景，从数据库、鉴权到展示，表单提交处理的 FaaS + Antd 的一体化研发，其目的是赋能前端掌控视图，释放业务服务端，提高需求交付效率。另外利用 Serverless 的 No Ops 和弹性扩容能力，可以降低前端开发服务的人力和资源成本。
to 服务端：对于 Java 服务端来说， FaaS 没有前端同学那么迫切的体感，其原因是 Java 应用本来就比较收敛，一个应用往往承载一类服务，不像前端那么离散。另外运维对于服务端同学也是必备技能，所以 No Ops 显得不是那么的有吸引力。对于服务端来说， FaaS 的定位主要是安放那些相对比较临时或者长尾的低流量服务，其目的就是保持应用的纯净度，避免变的臃肿难以维护。
Serverless的规划
对于飞猪来说，Serverless 的长远目标是 Serverless 定位的转变（技术探索 -> 生产力工具），服务端的开发模式的转变（Paas -> FaaS），前端职责的转变（端 -> 云 + 端）。这三个转变希望能在三年内完成，今年我们的重点是围绕着体验提升和稳定性夯实、场景扩展、内部开发平台和度量体系。
体验提升和稳定性夯实：体验提升主要是针对开发者，包括开发过程的调试以及上线后的灰度、回滚、监控，这部分主要依托集团的新研发平台去解决，飞猪这边更多是提出自己的诉求和参与部分的共建；稳定性的夯实主要是统一网关和监控体系，包括上线前的演练、压测以及上线后的监控、容灾。今年要做的是增加网关的 CDN 容灾，演练和压测常规化、标准化。另外就是共建 FaaS 的一体化监控体系，增加端到端的监控能力。
场景扩展：过去一年我们更多的是做基建和试点的技术探索，推动其成为生产力工具，今年我们的一个目标就是场景的扩展。为了达到这个目标，除了让前端外的团队具备认识和使用 FaaS 的能力，另外还在推动 Java FaaS 在飞猪的落地实践，毕竟 Java 才是服务端的主力，我们需要找到更多的 Java 场景。
内部开放平台：对于 FaaS 场景来说，更多是对于底层服务的二次封装来快速满足业务的需求交付，由一堆相对原子服务拼成一个符合自己需求的服务，所以我们需要让 FaaS开发同学能够快速找到自己所需的原子服务。我们的思路是通过集团的服务市场打造飞猪的内部开发平台，将原子服务沉淀到这里，日积月累，从而支撑更多业务需求的快速开发上线。
度量体系：上面也有提过， FaaS 最大的好处是提效和节省资源，今年我们希望能够将度量效率和资源的提升量化，目标是大幅节省机器数量，这里的节省主要是靠原有 PaaS 应用迁移到 Serverless 和弹性扩容完成。
结语
我们处在前端最好的时代，前有 React、Vue 框架配合 Webpack、Umi 解决端侧开发的体验和效率的问题，后有 Serverless 给前端插上了一对“翅膀”，赋予了本来只能在最底端做展示交互的前端工程师“翱翔云上”的能力。
Serverless 是未来，而且未来已来，它带来的 No Ops 和弹性扩容、按量收费能给企业节省大量的人力和资金成本，它将是未来开发模式的基础“水电煤”，早日加入 Serverless 的技术浪潮中，就会早日受益。
更多阅读推荐